home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1719.txt < prev    next >
Text File  |  1997-04-01  |  11KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           P. Gross
  8. Request for Comments: 1719                                           MCI
  9. Category: Informational                                    December 1994
  10.  
  11.  
  12.                           A Direction for IPng
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document was submitted to the IPng Area in response to RFC 1550.
  23.    Publication of this document does not imply acceptance by the IPng
  24.    Area of any ideas expressed within.  Comments should be submitted to
  25.    the big-internet@munnari.oz.au mailing list.  This RFC specifies
  26.    criteria related to mobility for consideration in design and
  27.    selection of the Next Generation of IP.
  28.  
  29. Table of Contents
  30.  
  31.    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
  32.    2.   A Direction for IPng . . . . . . . . . . . . . . . . . . . . 2
  33.    3.   Issues Toward IPng Resolution. . . . . . . . . . . . . . . . 3
  34.    4.   Security Considerations. . . . . . . . . . . . . . . . . . . 5
  35.    5.   Author's Address . . . . . . . . . . . . . . . . . . . . . . 5
  36.  
  37. 1. Introduction
  38.  
  39.    At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
  40.    BOF", on the process and progress of the IPng activities.
  41.  
  42.    ("IPng" stands for "IP, the next generation".   The IPDecide BOF was
  43.    chaired by Brian Carpenter.  Minutes are available in the IETF
  44.    directories, with the file name </ietf/93jul/ipdecide-minutes-
  45.    93jul.txt>.)
  46.  
  47.    The IPDecide BOF explored several facets of the IPng process, such
  48.    as:
  49.  
  50.       "What is the basis for choosing the next generation IP (i.e., what
  51.       are the technical requirements and decision criteria)."
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Gross                                                           [Page 1]
  59.  
  60. RFC 1719                  A Direction for IPng             December 1994
  61.  
  62.  
  63.       "With the advent of CIDR and new, more stringent address
  64.       assignment policies, are we comfortable that we truly understand
  65.       the level of urgency?"
  66.  
  67.       "Should the IETF or the marketplace make the final IPng decision".
  68.  
  69.    The BOF was held in a productive atmosphere, but did not achieve what
  70.    could be called a clear consensus among the assembled attendees.  In
  71.    fact, despite its generally productive spirit, it did more to
  72.    highlight the lack of a firm direction than to create it.
  73.  
  74.    The IPDecide BOF was followed the next evening by the open IESG
  75.    plenary. During this session, the IESG and the assembled attendees
  76.    discussed the IPng issues and seemed to arrive at a consensus based
  77.    on the following set of bullets presented by the IETF chair:
  78.  
  79.       "The IETF needs to move toward closure on IPng."  That is, the
  80.       IETF should take active steps toward a technical decision, rather
  81.       than waiting for the "marketplace" to decide.
  82.  
  83.       "The IESG has the responsibility for developing an IPng
  84.       recommendation for the Internet community."  That is, the IESG
  85.       should provide leadership and take specific actions to help move
  86.       the IETF toward a technical decision.
  87.  
  88.       "The procedures of the recommendation-making process should be
  89.       open and published well in advance by the IESG."
  90.  
  91.       "As a part of the process, the IPng WGs may be given new
  92.       milestones and other guidance to aid the IESG."
  93.  
  94.       "There should be ample opportunity for community comment prior to
  95.       final IESG recommendation (e.g., there will be an extended Last
  96.       Call)."
  97.  
  98. 2. A Direction For IPng
  99.  
  100.    Building on this consensus, I'd like to announce a set of specific
  101.    directions in the IESG that I hope will move us toward timely
  102.    resolution of many of the key IPng issues.
  103.  
  104.    The IESG will establish a temporary, ad hoc, "area" to deal
  105.    specifically with IPng  issues.  The charter for this new IESG area
  106.    is to develop a recommendation on which, if any, of the current
  107.    proposals should be adopted as the "next IP".  This recommendation
  108.    will be submitted to the IESG and to the Internet community for
  109.    review.  Following an adequate period of review to surface any
  110.    community concerns, the IESG will issue a final IPng recommendation.
  111.  
  112.  
  113.  
  114. Gross                                                           [Page 2]
  115.  
  116. RFC 1719                  A Direction for IPng             December 1994
  117.  
  118.  
  119.    All of the current IPng-related working groups will be moved
  120.    immediately into this new area.
  121.  
  122.    This new area will be headed by two co-Area Directors from within the
  123.    IESG. I have asked Allison Mankin (NRL), current Transport Services
  124.    AD, and Scott Bradner (Harvard), current Operational Requirements AD,
  125.    to serve as co-AD's for this temporary area.  I am very pleased to
  126.    report that they have agreed to take this important assignment.
  127.    (Because this is expected to be a temporary assignment, Scott and
  128.    Allison will also continue to serve in their current IESG positions
  129.    during this period.)
  130.  
  131.    All IETF Areas are now expected to have Area Directorates.  For the
  132.    IPng Area, a Directorate will be especially important to bring
  133.    additional viewpoints into the process.  Therefore, I am asking that,
  134.    as their first action, Scott and Allison form a specific IPng
  135.    Directorate to act as a direction-setting and preliminary review
  136.    body.  The IPng process will continue to be completely open, and
  137.    therefore reports and meeting notes from any IPng Directorate
  138.    meetings will be published in timely fashion.
  139.  
  140. 3. Issues Toward IPng Resolution
  141.  
  142.    Two important issues need resolution immediately before we can expect
  143.    progress toward an IPng recommendation:
  144.  
  145.       - What is the scope of the effort?
  146.  
  147.       That is, should IPng be limited to solving the well known scaling
  148.       and address exhaustion issues; or should IPng also include
  149.       advanced features such as resource reservation for real-time
  150.       traffic?
  151.  
  152.       The argument in favor of considering advanced features is that
  153.       migration to a new IP is (hopefully, only!) a once-in-a-generation
  154.       occurrence, and therefore all advanced features should at least be
  155.       considered.
  156.  
  157.       Arguments opposed to considering advanced features include the
  158.       fact that we may not have time for this level of effort before the
  159.       scaling and address exhaustion problems confront us, and that we
  160.       may not have the necessary understanding and experience to make
  161.       all the correct choices at this time.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Gross                                                           [Page 3]
  171.  
  172. RFC 1719                  A Direction for IPng             December 1994
  173.  
  174.  
  175.       - What is the available timeframe?
  176.  
  177.       That is, before we can even begin to make an informed decision
  178.       about the scope, we need a better understanding of the urgency and
  179.       time constraints facing us.
  180.  
  181.       Factors that affect the available time include the current rate of
  182.       address assignments (which can give us an estimate of when we are
  183.       currently projected to run out of addresses), the current policies
  184.       governing address assignment (which can give us an understanding
  185.       of how policies affect the assignment and utilization rates), the
  186.       impact of CIDR aggregation, the development time for IPng, and the
  187.       time needed to field and migrate to the new IPng.
  188.  
  189.    Therefore, I am asking the new AD's and the Directorate to start
  190.    immediately the following specific activities to help guide their
  191.    ultimate IPng recommendation:
  192.  
  193.       1. Develop an understanding of the available timeframe, covering
  194.       at least the following issues:
  195.  
  196.          - Review Internet growth metrics, such as the current address
  197.          assignment and utilization rates.  Develop an understanding of
  198.          how the new address assignment policies impact the assignment
  199.          and utilization rates.
  200.  
  201.          - Review the expected impact of CIDR address aggregation.
  202.          Develop an understanding of the expected savings due to CIDR
  203.          aggregation.
  204.  
  205.          - Develop new technical guidelines for classless Internet
  206.          addressing.  Specific examples include guidelines for how to
  207.          utilize variable length subnet masks, and how to utilize
  208.          currently unused Class A and B addresses in a classless fashion
  209.          in hosts and routers.
  210.  
  211.          - Develop a strong understanding of the time required for the
  212.          development, fielding, and migration for a new IP.
  213.  
  214.          - Based on all the above issues,
  215.  
  216.             (a) develop an estimate for how long we have to develop
  217.             and deploy an IPng.  This could be a set of estimates
  218.             based on best/worst case estimates for how each of the
  219.             above factors will affect the available timeframe.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Gross                                                           [Page 4]
  227.  
  228. RFC 1719                  A Direction for IPng             December 1994
  229.  
  230.  
  231.             (b) Consider whether more stringent assignment policies
  232.             might provide additional time.  If so, recommend such
  233.             policies.
  234.  
  235.             (c) make a recommendation on whether it is worthwhile to
  236.             mount a serious effort to reclaim addresses and/or to
  237.             renumber significant portions of the Internet.
  238.  
  239.       2. Based on an informed judgment of the time constraints above,
  240.       make a recommendation regarding the scope for IPng, i.e., should
  241.       IPng consider scaling issues only or advanced topics also.
  242.  
  243.       3. Based on the scope and time constraints, develop a clear and
  244.       concise set of technical requirements and decision criteria for
  245.       IPng.  These should include, but not be limited to, the criteria
  246.       outlined in the IESG statement (RFC1380).
  247.  
  248.       4. Based on the decision criteria, scope, and time constraints,
  249.       make a recommendation on which of the current IPng candidates to
  250.       accept, if any.
  251.  
  252.       Finally, I am asking Scott and Allison to make a detailed report
  253.       at the opening plenary of the next IETF meeting in November on the
  254.       status of setting up their new area, and on their progress toward
  255.       organizing the above work items.  In particular, the status of the
  256.       work items on timeframe should be fully reported. This will be
  257.       followed by regular progress reports to the Internet community, at
  258.       IETF meetings and in other appropriate forums.
  259.  
  260.    Please join me in giving Scott and Allison our full cooperation, and
  261.    in thanking them for accepting this daunting assignment.  I feel
  262.    confident that we will now make significant progress on the important
  263.    IPng issues facing the Internet community.
  264.  
  265. 4. Security Considerations
  266.  
  267.    Security issues are not discussed in this memo.
  268.  
  269. 5. Author's Address
  270.  
  271.    Phill Gross
  272.    Director of Internet Engineering
  273.    MCI Data Services Division
  274.    2100 Reston Parkway FL 6
  275.    Reston, VA   22091
  276.  
  277.    Phone: 703-715-7431
  278.    EMail: phill_gross@mcimail.com
  279.  
  280.  
  281.  
  282. Gross                                                           [Page 5]
  283.  
  284. RFC 1719                  A Direction for IPng             December 1994
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Gross                                                           [Page 6]
  339.  
  340.